Computer-implemented system and method for code generation

ABSTRACT

A computer-implemented system and method for generating code. The system and method receive source code that includes a higher order computer language statement. Machine code is generated from the received source code. The generated machine code is placed directly into volatile memory for access by a computer program.

TECHNICAL FIELD

[0001] The present invention relates generally to computer codegeneration and more particularly to computer code compiling.

BACKGROUND

[0002] Most computer programs require preexisting object files in orderto execute their instructions. If the programs' instructions were tochange, then typically the programs' underlying source code is modifiedoff-line and recompiled into an object file stored on a computer harddisk. The modified program is then available for execution.

SUMMARY

[0003] In accordance with the teachings disclosed herein, acomputer-implemented system and method are provided for generating code.The system and method receive source code that includes higher ordercomputer language statements. Machine code is generated directly intoRAM from the received source code.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004]FIG. 1 is a block diagram depicting software and computercomponents used in generating code;

[0005]FIG. 2 is a block diagram depicting application programminginterfaces used in generating code;

[0006]FIG. 3 is a block diagram depicting relocation types;

[0007]FIG. 4 is a block diagram depicting additional exemplaryapplication programming interfaces utilized in generating code;

[0008]FIG. 5 is a block diagram depicting a debugger utilized in thecode generation process;

[0009]FIGS. 6A and 6B are flowcharts depicting exemplary operationalsteps for code generation;

[0010]FIG. 7 is a block diagram depicting an exemplary application ofthe code generation system;

[0011]FIG. 8 is source code output depicting a search function generatedwithout the code generation system;

[0012]FIG. 9 is source code output depicting a search function generatedvia the code generation system;

[0013] FIGS. 10-12 are block diagrams depicting additional uses for acode generation system;

[0014]FIG. 13 is a block diagram depicting exception handling techniquesinvolving a code generation system;

[0015]FIG. 14 is a block diagram depicting exception handling techniquesinvolving a C code generation system; and

[0016]FIGS. 15A and 15B are flowcharts depicting exemplary operationalsteps for exception handling techniques involving the code generationsystem of FIG. 14.

DETAILED DESCRIPTION

[0017]FIG. 1 depicts a computer-implemented system 30 that generatesmachine code 32 at run-time for use by an application 33. Source code 34(containing functions needed by the application 33) is provided to acode generator software module 36. The module 36 generates machine code32 directly to random access memory 38 (RAM) from the source code 66 andallows the application 33 to access the functions contained in themachine code 32.

[0018] As an example, the application 33 may wish to run a data search.The source code 34 to handle the data search is created during run-timeof the application 33. The module 36 generates directly to RAM themachine code 32 from the data searching source code 34. The generator 36makes available function pointers 40 so that the application 33 may callthe data searching functions contained within the machine code 32. Theapplication 33 can call these function pointers 40 as it would any otherfunction pointer.

[0019]FIG. 2 shows another code generation system 60 wherein applicationprogramming interfaces 62 (APIs) are used an application 64 to interactwith the generator 68 and the machine code 72. In this system, theapplication 64 contains instructions 65 to create source code 66on-the-fly. The application submits the source code 66 to the generator68 via one of the APIs 62. The submitted source code 66 may be formattedas ASCII text (or some other format recognizable by the generator 68)and may be in any higher order language (e.g., C, C++, FORTRAN, Pascal,assembly, etc.).

[0020] The application 64 may also use the APIs 62 to export datasymbols, function symbols, and structures 70 so that they may be usedduring the machine code generation process. This is done when thegenerated code stream 72 needs to call back into the code of theapplication 64. To support this, the application 64 is allowed to exportcode symbols 70 in the form of function pointers, to the generator 68.When the generated code stream 72 needs to have access to data in theapplication program 64, the application 64 may export data to the codestream 72.

[0021] The generator 68 creates the machine code 72 from the source code66 and from the exported information 70 and places the machine codestream 72 into RAM 74 as the machine code 72 is generated. It is notedthat the generated machine code 72 is fully resolved and containsphysical memory addresses. Also generated and included in the codestream 72 is any data required by the generated machine code. Thegenerator 68 creates function pointers 76 so that the application 64 maylocate where the functions are located in RAM 74.

[0022] Because the generated machine code 72 goes directly into memory74 instead of to an object file, there are no “link” or “load” phases,so relocation is performed during the generator's compiling process. Thespecific types of relocations are dependent on the target machine, butillustrated in FIG. 3 are several general types of relocations that areresolved by the code generation system.

[0023]FIG. 3 depicts several different relocation operations types thatmay be used when the generator creates functions 90 or global data 92.More specifically, relocation addresses the situation when a generatedfunction wishes to access another generated function or a generatedfunction wishes to access generated global data. For example, relocationoccurs when there is code to code relocation inside of a generatedfunction as shown at reference number 101. These are used forconditional and unconditional branches, and may be absolute orpc-relative, depending on the platform.

[0024] As shown at reference number 102, another type of relocation iscode to code relocation between generated functions. This is used forfunction calls or for taking the address of another function (so that itcan point to the start of the function). Reference number 103illustrates data to code relocation so that statically initializedpointers may point to the start of a function. Reference number 104illustrates code to data relocation to obtain the address of a member ofglobal data. Reference number 105 illustrates data to data relocation sothat statically initialized pointers may point to data.

[0025]FIG. 4 shows examples of different APIs 62 that an application 64may use in generating the machine code 72 that it needs. The APIs 62 mayinclude a method for an application to set code generation options. Forexample, a code generation option may indicate whether the generator 68optimizes the machine code 72. Another option may be to specify that adifferent on-the-fly code generator be used (such as one to handle adifferent type of source code language). The APIs 62 may include amethod to free some or all of the resources needed by the codegenerator, including the memory associated with the code stream.

[0026]FIG. 5 depicts a debugger 120 to assist a user in analyzingperformance or errors that arise during the compiling of the source code66 or execution of the machine code 72. For these debugging operations,another region of memory is used to describe the machine code 72. Thedebugger 120 accesses this memory region to retrieve and provide thedescription to the user.

[0027] The description allows the input source code 66 to be shownalongside of the machine code instruction(s) 72 to be executed. Thedescription contains the current data values and the machine codeinstruction that is next to be executed. In this way, a user can analyzestep-by-step the operation of the machine code 72. The debugger 120 mayalso access the code within the application 64 so that a user mayexamine the effect the application's execution has upon the machine code72.

[0028]FIGS. 6A and 6B depict exemplary operational steps for codegeneration. With reference to FIG. 6A, start indication block 150indicates that process block 152 is executed. At process block 152, acomputer program creates source code that is to supply one or moredesired functions. The computer program exports data symbols, functionsymbols, and structures at process block 154. At process block 156, thecomputer program launches a code generation program in order to processthe newly created source code. It should be understood that many otherways exist for handling the execution of the code generation program,such as not having the computer program launch the code generationprogram, but having the code generation program in a hibernation statewaiting to be invoked by the computer program.

[0029] Continuation block A 158 indicates that processing continues onFIG. 6B at process block 160. With reference to FIG. 6B, machine code isgenerated directly into RAM from the source code at process block 160.Process block 160 considers during the compiling of the source code anycompiler options supplied by the application as well as handling anyrelocations needed.

[0030] Any errors arising during compiling are detected by decisionblock 162. If no errors arise, then at process block 164 the computerprogram accesses the functions and data contained in the machine code.Processing in this operational scenario terminates at end block 168. Ifan error did arise during compilation, then the error is analyzed viathe debugger at process block 166.

[0031]FIG. 7 depicts an exemplary use of the code generation system 60.In this example, the application 64 generates different lines of sourcecode depending upon the type of situation it encounters. The application64 contains code to detect whether a first situation 200 or secondsituation 202 has occurred. If the first situation 200 occurs, then theapplication 64 generates first source code 204 for conversion intomachine code 72. If the second situation 202 occurs, then theapplication 64 generates second source code 206 for conversion intomachine code 72. For example, the application 64 may generate theinstructions for the first source code 204 in order to more efficientlyhandle one type of data (e.g., real numbers), whereas it will generatedifferent instructions for the second source code 206 to moreefficiently handle a different type of data (e.g., text). In such a way,the code that works best in a particular situation is used. It should beunderstood that the code generation system 60 is not limited to only twotypes of situations, but may include any number that reflects thesituation at hand. The instructions of the first and second source code(204 and 206) may differ in that each source code alters a generalalgorithm differently to better tailor the algorithm for the specificsof its own situation. For example, the application 64 may alterdifferently a B*tree searching algorithm to improve the searching ofdifferent types of data depending upon the situation at hand.

[0032]FIGS. 8 and 9 illustrate how an application may alter source codefrom a typical algorithm. FIG. 8 shows source code instructions thatwere generated based upon a typical B*tree search algorithm withoutusing the code generation system. The source code of FIG. 8 has toaccount for many different scenarios as it has not been honed for aparticular situation.

[0033]FIG. 9 shows a set of more efficient source code instructions thatwere generated via the code generation system. The source code of FIG. 9illustrates that the code generation system can be used to generate moreefficient source code in that it has been tailored during runtime tobetter fit the situation at hand. For example, the source code of FIG. 9has been customized for a B*tree search with a key type of double andwith no concurrency. The application discerned the data sortingsituation it was confronted with and used the APIs to generate thesource code of FIG. 9.

[0034] Situations may become even more complicated as a B*tree computerprogram may request an unlimited variety of key-types and data-types.Coding for all the possibilities without the code generation system isquite complex and inefficient. The code generation system provides a wayto generate customized code for the particular B*tree situation at hand.The following provides specific exemplary considerations that may beused in deciding how to create the optimal source code for the B*treesituation at hand:

[0035] Concurrency: Concurrent operations provide the ability to allowmultiple threads access to the same tree at the same time. The code toprovide concurrent operations is very complex. The complexity reducesperformance. There are cases when concurrency is not desired by theconsumer Source code may be generated to provide the ability to includeor not include the code required to provide concurrent operations. Thisability to customize on the fly significantly enhances the efficiency ofthe B*tree.

[0036] Key Type: Consumers of the B*tree request a variety of key types.Each key type requires a compare function. The compare functions areattached to the instance handle of the of B*tree. The code generationsystem provides a way for the compare code to be generated in-line thuseliminating the need for compare function calls. Also, the in-linegenerated code is customized for the dimension count and complex keyshaving more than one data type.

[0037] Dimension Count: A key type has a dimension count. In thesimplest case the dimension count is “one” and the compare involves asingle comparison. The code generation system may be used to eliminatethe need for a dimension count dependent for-loop, thereby greatlyimproving the compare code's performance.

[0038] Paging: Traditional B*trees are pagable however the consumer maybe provided with the ability to request no paging if she is dealing withan index that can fit entirely in-memory. In-memory B*tree's performanceis greatly improved due to the fact that secondary storage is notrequired.

[0039] Duplicate Keys: Traditional B*trees do not entertain the notionof duplicate keys. A B*tree generated via the code generation systemcan, allow multiple inserts of the same key. The code generation systemprovides the consumer with the ability to generate or not generate codefor this functionality.

[0040] The following discusses different APIs that an application maywish to use in relation to the code generation process. The applicationmay wish to have access to an API that creates a code generator instanceas well as to APIs that provide code generator service routines. Suchcode generator service routines may be used to: define externalfunctions and data items; define structures; define preprocessor macros;convert a compile-time macro to a string that can be added to the sourcebuffer; set compiler options from a string; set a compiler option;obtain the current value of a compiler option; enable/disable process IDchecking; add a source code line to the compiler source buffer; addpartial source lines to the compiler source buffer; format and addsource code to the compiler source buffer; erase all C source code fromthe compiler source buffer; obtain a pointer to the internal compilersource buffer; compile the code in the source buffer and return a handleto manage the generated code stream; and destroy the code generatorinstance. The APIs may also provide the following code stream servicesin order to: obtain the address of a generated function; obtain the nameof a generated function; and destroy the code stream instance.

[0041] The following illustrates use of various APIs in the codegeneration process. When the generated code stream needs to call backinto the application code, the application code exports code symbols inthe form of function pointers to the code generator by using thefollowing code: void function(void) { return 1; } tkgDefineExtern(tkgh,“function”, function);

[0042] (Note: the tkgDefineExtern function defines external functionsand uses three arguments: 1) handle to code generator, 2) name toexport, 3) address of symbol.) The application would then submit code todefine this function in the code stream as follows:

[0043] TkgAppendCSource(tkgh, “void function(void);\n”, −1);

[0044] (Note: the TkgAppendCSource function adds a source code line tothe compiler source buffer and uses three arguments: 1) handle to codegenerator, 2) string containing source to be added, 3) length of string(wherein −1 means NULL terminated).)

[0045] The code stream can now call the ‘function’. Note that thecalling conventions on some platforms require that a register be set upto point the global data area of each shared library (DLL). Because inthis example, ‘function’ appears in a different shared library from therest of the generated code stream, the direct function call is convertedto a function pointer call, so the data pointer can be loaded as part ofthe normal calling sequence of a function pointer call.

[0046] When the generated code stream needs to access data in theapplication program, the application can export data to the code streamas follows: int mtable[200]; . . . tkgDefineExtern(tkgh, “mytable”,mytable);

[0047] The application then submits the code to define symbol as anexternal data item.

[0048] tkgAppendCSource(tkgh, “extern int mytable[200];\n”, −1);

[0049] Note that the generated code stream treats the data item as anexternal global symbol, but this symbol need not be a global symbol inthe application program.

[0050] The routines tkgAppendCSource( ) and tkgFormatCSource( ) allowthe application to submit “C” source code to the code generator. Onceall the external symbols are defined, and all the “C” source has beensubmitted, the application calls tkgGenerate( ) to cause the source codeto be compiled into machine code. This function construct a C functionpointer that can be called from the context of the application program.On some architectures, this is returning the address of the code stream.On others, a function descriptor is created which contains the addressof the code, and any other necessary information to make a successfulfunction pointer call, i.e., address of the global data pointer. Thefunction pointer obtained from tkgGetFuncAddr( ) can be cast to afunction pointer of the appropriate type, and called like any otherfunction pointer.

[0051] (Note that the tkgFormatCSource function formats and adds sourcecode to the compiler source buffer and uses in this example thefollowing arguments: 1) handle to code generator, 2) varargs“printf-style” list of arguments. The tkgGenerate function compiles thecode in the source buffer and returns a handle to manage the generatedcode stream. The function uses in this example uses the followingarguments: 1) handle to code generator, 2) IO (input/output) handle towrite error messages to, 3) name of codestream (for debugger use). ThetkgGetFuncAddr function in this example uses the following arguments: 1)handle to code stream, and 2) name of function.)

[0052] It is often desirable for generated code to reference data instructures defined by the application. Structures that the generatedcode stream references will need are defined in the incoming sourcecode. To reduce the amount of dual maintenance in maintaining astructure definition in two locations (such as one in application headerfiles, and the other in a series of tkgAppendCSource statements), amethod is used to describe only the members that the code streamrequires. If members are added to the application version, the offsetsto the code stream version are automatically adjusted. To illustratethis, the tkgDefineStructList( ) API is discussed. This API allows astructure to be defined for the generated code to use. If theapplication developer modifies the structure, the definition sent to thecode generator is automatically updated (note that in this C languageexample, this would be due to the use of the standard C offsetof( )operator).

[0053] First, a set of helper macros are defined as:

[0054] #define MEMSIZE(str,mem) sizeof(((str *)0)->mem)

[0055] #define TKMEMDEF(mem, str, decl) {#mem, MEMSIZE(struct str,mem),offsetof(struct str,mem), decl},

[0056] #define TKINTDEF(mem, str) TKMEMDEF(mem, str, “int % s”)

[0057] #define TKLONGDEF(mem, str) TKMEMDEF(mem, str, “long % s”)

[0058] #define TKDBLDEF(mem, str) TKMEMDEF(mem, str, “double % s”)

[0059] #define TKPTRDEF(mem, str) TKMEMDEF(mem, str, “void * % s”)

[0060] #define TKCHRDEF(mem, str) TKMEMDEF(mem, str, “char % s”)

[0061] #define TKMEMEND {NULL,0,0,NULL}

[0062] The following provides a description of these macros:

[0063] “#define MEMSIZE(str,mem) sizeof(((str *)0)->mem)” is used todetermine the size of a member in a structure, where str is thestructure name and mem is the member in the structure.

[0064] “#define TKMEMDEF(mem, str, decl) {#mem, MEMSIZE(struct str,mem),offsetof(struct str,mem), decl}” is used to define a member of astructure, where mem is the member of the structure, str is the name ofthe structure, decl is a string that will be sent to the code generatorthat will be used to define the member.

[0065] “#define TKINTDEF(mem, str) TKMEMDEF(mem, str, “int % s”)” isused to define a member of type int based on TKMEMDEF above, where memis the name of the member and str is the name of the structure.

[0066] “#define TKLONGDEF(mem, str) TKMEMDEF(mem, str, “long % s”)” isused to define a member of type long based on TKMEMDEF above, where memis the name of the member and str is the name of the structure.

[0067] “#define TKDBLDEF(mem, str) TKMEMDEF(mem, str, “double % s”)” isused to define a member of type double based on TKMEMDEF above, wheremem is the name of the member and str is the name of the structure.

[0068] “#define TKPTRDEF(mem, str) TKMEMDEF(mem, str, “void * % s”)” isused to define a member of pointer type based on TKMEMDEF above, wheremem is the name of the member and str is the name of the structure.

[0069] “#define TKCHRDEF(mem, str) TKMEMDEF(mem, str, “char % s”)” isused to define a member of type char based on TKMEMDEF above, where memis the name of the member and str is the name of the structure.

[0070] “#define TKSTRUCTDEF(str, memlist) {#str, sizeof(struct str),memlist}” is used to define a structure with a list of members, wherestr is the name of the structure and memlist is the list of members.

[0071] “#define TKMEMEND {NULL,0,0,NULL}” is used to mark the end of astructure.

[0072] These macros are used to set up a data structure representing astructure. As an example, suppose that we have the following structurecalled FOO: struct FOO { int a; double d; int aa; void *x; int aaa; void(*func)(int, double); int aaaa; };

[0073] Suppose we wish to allow the generated code to have access tomembers ‘a’,‘d’,‘x’, and ‘func’. A data structure may be set up and maydescribe a structure FOO as follows: TKGMemDef FOO_memdefs[] = {TKINTDEF(a, FOO) TKDBLDEF(d, FOO) TKPTRDEF(x, FOO) TKMEMDEF(func, FOO,“void (*%s)(int, double)”) TKMEMEND }; TKGStructDef structdefs[] = {TKSTRUCTDEF(FOO, FOO_memdefs) };

[0074] Then the application calls tkgDefineStructList( ) as follows:

[0075] tkgDefineStructList(tkgh, structdefs, 1);

[0076] (where the three arguments of tkgDefineStructList( ) are: 1)handle to code generator, 2) data structure defining the structure wewant to export to generated code. 3) Number of structures.) Through thismethod, the struct FOO can be modified (e.g., additional members added),and the code to export it to generated code does not need to change(unless the generated code needs access to a new member).

[0077] While examples have been used to disclose the invention,including the best mode, and also to enable any person skilled in theart to make and use the invention, the patentable scope of the inventionis defined by the claims, and may include other examples that occur tothose skilled in the art. As an example of the wide scope attributableto the code generation system and method, FIG. 10 illustrates adifferent scenario wherein source code 66 is generated by a firstapplication 250 for use by a second application 252. The firstapplication 250 may send a message or set a semaphore to notify thesecond application 252 when it may access the function(s) contained inthe machine code (or the second application can alternatively check tosee if the designed function pointer is available). Also it should beunderstood that the code generation system and method may be used bymultiple applications. Accordingly a third application can launchanother generator program and submit source code to it so that thesource code may be processed by the second generator program; or thethird application may access the same generator program as the firstapplication in FIG. 10.

[0078] A wide range of computer applications may use the code generationsystem 60. As an illustration, FIG. 11 shows a multi-threaded systemwhere the applications (250 and 252) and code generator 68 operate asthreads. Concurrency mechanisms 280 as commonly used in the field areemployed to notify when machine code 72 is available for use by anapplication.

[0079] As shown in FIG. 12, the code generation system 60 allows theapplication 250 that generated the source code 66 for use by otherapplications 252 to also be able to access the functions contained inthe machine code 72.

[0080] The code generation system may be used on many different types ofcomputer architectures and may be implemented in different ways. As anillustration, the generator module may co-exist on the same computer ordevice that contains the applications that generate and use the machinecode. In another implementation, the generator module may reside on afirst computer while the applications reside on a second computer; thegenerated machine code is placed directly into RAM device(s) that theapplications can access. Also, the code generation software may bestored on many different types of computer readable media, such as forstorage, delivery to a user, for execution, etc., as well as using aflash memory device (that is in the address space of the program thatgenerates the source code) in substitution for the RAM device.

[0081] As a further example of the wide scope of the code generationsystem, the code generation system may be tailored to perform run-timeexception handling more efficiently. With reference to FIG. 13, the codegeneration system 30 uses an exception handling generation extension 300to add exception branching functionality 320 and exception catchingfunctionality 322 for when an exception happens.

[0082] When an exception happens, an exception signal handler 310 allowsexecution to resume at the recovery code contained within the exceptioncatching functionality 322. The exception signal handler 310accomplishes this by placing the value stored from the exceptionbranching functionality 320 into the PC (program counter) slot of theexception context structure that was passed to the exception signalhandler 310. The exception signal handler 310 then returns, andexecution continues via the exception catching functionality 322.

[0083] The exception handling techniques may be used with source code ofmany different types of higher order languages, such as C, FORTRAN,Pascal, assembly, etc. FIG. 14 shows an example where an exceptionhandling generation extension 350 allows a C machine code generator 340to add to generated machine code 32 exception functionality that mayresemble: ON_EXCEPTION_GOTO(label); . . . [code goes here that couldpossible cause an exception] . . . EXCEPTION_LABEL(label) . . .[recovery code to continue after an exception goes here] . . .

[0084] The ON_EXCEPTION_GOTO( ) statement 370 is a relatively fastoperation that records the location of the recovery code located at theexception label 372. The ON_EXCEPTION_GOTO( ) statement 370 may beplaced at any point within the generated source code 34. For example,the ON_EXCEPTION_GOTO( ) statement 370 may be placed in the beginning ofthe generated source code 34 in order to have exception handlingtechniques available from the execution's start. Because theexception-related statements (370 and 372) are being generatedon-the-fly by the application 33 (e.g., a data mining application, adatabase application, a statistical application, etc.), the exceptionhandling statements (370 and 372) may be tailored/customized for thesituation at hand. The customization may include placing one or more ofthe exception-related statements (370 and 372) in different locationswithin the generated source code 34 based upon the application's currentexecution context. The customization may also include generatingdifferent recovery code based upon the application's current executioncontext. For example, the program may have attempted to compute amultiplication of two very large numbers. This would cause a floatingpoint overflow exception. The recovery code could choose to set theresult to the largest possible floating point number, and continueexecution.

[0085] With the extension 350, the C machine code generator 340 cangenerate on-the-fly machine code 32 directly into RAM such thatexecution resumes at the EXCEPTION_LABEL( ) statement 372 no matterwhere in the machine code 32 the exception happens. To resume executionat the recovery code, an exception signal handler 360 places the valuestored from the ON_EXCEPTION_GOTO( ) statement 370 into the PC (programcounter) slot of the exception context structure that was passed to theexception signal handler 360. The exception signal handler 360 thenreturns, and execution continues at the EXCEPTION_LABEL( ) statement372.

[0086] It is noted that the recovery code can perform any actionsnecessary or useful for handling the exception at hand. For example, therecovery code may allow the executing program to recover from theexception, activate a debugging program to analyze the exception, orterminate the program gracefully.

[0087] The run-time exception handling techniques allow for thereduction or the elimination of having to continually save the contextof an executing program when trapping for exceptions. Moreover, theexception handling functionality may be extended to allow exceptionhandling code to be generated by the code generator that allows theexception handling to be turned off as well as turned back on.

[0088] The exception handling functionality may also handle many typesof exceptions, such as for example I/O interrupts (e.g., a personhitting control C while the program is executing), null pointerexceptions, overflow errors, or index outside the bounds of an array,etc. Other exception handling may include the recovery code allowinglocks to be properly released if the program is involved in aconcurrency situation.

[0089]FIGS. 15A and 15B depict exemplary operational steps for exceptionhandling techniques involving the C code generation system of FIG. 14.With reference to FIG. 15A, start block 400 indicates that process block402 executes. At process block 402, an application generates C sourcecode that contains an ON_EXCEPTION_GOTO( ) and EXCEPTION_LABEL( )statements, and process block 404 installs a signal handler.

[0090] At process block 406, a code generator module generates machinecode directly to RAM from the source code and allows the application toaccess the functions contained in the machine code. At process block408, the generated machine code hits the ON_EXCEPTION_GOTO( ) statementwhich causes the address of the recovery code to be recorded. Within thegenerated machine code, the code portion that could possibly cause anexception is executed at process block 410. Processing continues on FIG.15B as indicated by continuation block 412.

[0091] With reference to FIG. 15B, decision block 414 examines whetheran exception has occurred during execution. If no exception occurred,then execution continues at process block 416 before processing returnsfrom the generated machine code at process block 424.

[0092] However if an exception had occurred as determined by decisionblock 414, then the signal handler is invoked at process block 418. Atprocess block 420, the signal handler changes the PC in the exceptioncontext to the location recorded by the ON_EXCEPTION_GOTO( ) and returnsfrom the exception. At process block 422, the recovery code at theEXCEPTION_LABEL is executed, and execution continues at process block416 before processing returns from the generated machine code at processblock 424.

It is claimed:
 1. A computer-implemented method for generating machinecode, comprising the steps of: receiving source code that includes ahigher order computer language statement, said received source codehaving been created by a first computer program; generating machine codedirectly into random access memory (RAM) from the received source code;and providing a function pointer to the generated machine code stored inthe RAM so that a second computer program may access the generatedmachine code.
 2. The method of claim 1 wherein the first computerprogram is the second computer program.
 3. The method of claim 1 whereinthe first computer program comprises a different program than the secondcomputer program.
 4. The method of claim 1 wherein the first computerprogram and second computer program are modules contained within a thirdcomputer program.
 5. The method of claim 1 wherein the first computerprogram contains instructions to create source code on-the-fly.
 6. Themethod of claim 1 wherein the first computer program containsinstructions to automatically create source code on-the-fly, said sourcecode comprising a plurality of higher order computer languagestatements.
 7. The method of claim 1 wherein the source code isformatted as text.
 8. The method of claim 1 wherein the higher orderlevel computer language statement is based upon assembly language. 9.The method of claim 1 wherein the first computer program containsinstructions to generate first source code based upon occurrence of afirst situation and to generate second source code based upon occurrenceof a second situation, wherein if the first situation occurs, the firstsource code is used as the source code for generating the machine codedirectly into RAM; wherein if the second situation occurs, the secondsource code is used as the source code for generating the machine codedirectly into RAM.
 10. The method of claim 1 wherein the first computerprogram launches another computer program to perform said generatingmachine code step.
 11. The method of claim 1 wherein the first computerprogram and the second computer programs operate as threads.
 12. Themethod of claim 1 wherein a plurality of computer programs access thegenerated machine code through the function pointer.
 13. The method ofclaim 1 further comprising the step of: providing function pointers tothe generated machine code stored in the RAM so that the second computerprogram may access functions contained within the generated machinecode.
 14. The method of claim 1 wherein machine code is computer machinereadable code.
 15. The method of claim 14 wherein the machine codecomprises physical memory addresses.
 16. The method of claim 1 whereinthe machine code is generated at run-time.
 17. The method of claim 16wherein the machine code is generated during execution of the first andsecond computer programs.
 18. The method of claim 1 wherein the firstcomputer program uses an application programming interface (API) tosubmit the source code for generating the machine code.
 19. The methodof claim 1 wherein the second computer program uses an applicationprogramming interface (API) to access the generated machine code throughthe function pointer.
 20. The method of claim 1 wherein the firstcomputer program uses application programming interface (API) means tosubmit the source code for generating the machine code.
 21. The methodof claim 1 wherein the second computer program uses an applicationprogramming interface means (API) to access the generated machine codethrough the function pointer.
 22. The method of claim 1 wherein thefirst program exports programmatic data to be used during the machinecode generation process.
 23. The method of claim 22 wherein theprogrammatic data comprise data symbols, function symbols, andstructures.
 24. The method of claim 23 wherein the machine code utilizesthe exported programmatic data so that the machine code may call backinto the code of the application.
 25. The method of claim 1 furthercomprising the step of: performing relocation during generation of themachine code.
 26. The method of claim 25 wherein the generating stepdoes not include a link or load phase.
 27. The method of claim 25further comprising the step of: performing a code to code relocationwithin a generated function of the machine code.
 28. The method of claim25 further comprising the step of: performing a code to code relocationbetween two generated functions of the machine code.
 29. The method ofclaim 25 further comprising the step of: performing a data to coderelocation between generated data and generated function of the machinecode.
 30. The method of claim 25 further comprising the step of:performing a code to data relocation between generated function andgenerated data of the machine code.
 31. The method of claim 25 furthercomprising the step of: performing a data to data relocation forgenerated data of the machine code.
 32. The method of claim 1 furthercomprising the step of: setting a compiler option to affect thegeneration of the machine code.
 33. The method of claim 1 furthercomprising the step of: freeing resources associated with the generatedmachine code.
 34. The method of claim 1 further comprising the step of:freeing resources associated with the generated machine code after thegenerated machine code has executed.
 35. The method of claim 1 furthercomprising the step of: freeing memory associated with the generatedmachine code.
 36. The method of claim 1 further comprising the step of:using a debugger to analyze a compilation error associated with thegeneration of the machine code.
 37. The method of claim 1 furthercomprising the step of: using debugger means to analyze the generatedmachine code.
 38. The method of claim 1 wherein the source code isdirected to a B*tree operation, wherein the first computer programcontains instructions to generate differently source code based uponwhether concurrency is desired or not.
 39. The method of claim 1 whereinthe source code is directed to a B*tree operation, wherein the firstcomputer program contains instructions to generate differently sourcecode for when different key types are requested.
 40. The method of claim39 wherein the generated source code is customized based upon dimensioncount.
 41. The method of claim 40 wherein the generated source code iscustomized based upon complex keys having more than one data type. 42.The method of claim 1 wherein the source code is directed to a B*treeoperation, wherein the first computer program contains instructions togenerate differently source code based upon whether a dimension countdependent for-loop is needed for the B*tree operation.
 43. The method ofclaim 1 wherein the source code is directed to a B*tree operation,wherein the first computer program contains instructions to generatedifferently source code for when different key types are requested. 44.The method of claim 1 wherein the source code is directed to a B*treeoperation, wherein the first computer program contains instructions togenerate differently source code for when no paging is requested. 45.The method of claim 44 wherein paging is not requested when an index canfit entirely in-memory.
 46. The method of claim 1 wherein the sourcecode is directed to a B*tree operation, wherein the first computerprogram contains instructions to generate differently source code forwhen multiple inserts of the same key are requested.
 47. The method ofclaim 1 wherein an application generates the source code, said sourcecode containing a structure that references data in a structurecontained within the application.
 48. The method of claim 47 wherein thesource code defines only the data that the generated machine coderequires for its operation.
 49. The method of claim 47 wherein thestructure contained within the source code is updated if the structurecontained within the application is modified.
 50. The method of claim 49wherein additional members are added to the structure contained withinthe application, wherein offsets to the structure contained within thesource code are automatically updated.
 51. A computer-implementedapparatus for generating machine code, comprising: a generator modulethat generates machine code directly into random access memory (RAM)from source code, said source code including a higher order computerlanguage statement, said source code having been provided to thegenerator module by a first computer program; a relocation handler thatperforms relocation operations during generation of the machine code;said generator module providing a function pointer to the generatedmachine code stored in the RAM so that a second computer program mayaccess the generated machine code.
 52. A computer-implemented apparatusfor generating machine code, comprising: means for receiving source codethat includes a higher order computer language statement, said receivedsource code having been created by a first computer program; means forgenerating machine code directly into random access memory (RAM) fromthe received source code; and means for providing a function pointer tothe generated machine code stored in the RAM so that a second computerprogram may access the generated machine code.
 53. The apparatus ofclaim 52 further comprising: an application having code generation meansfor generating the source code.
 54. The apparatus of claim 53 whereinthe code generation means comprises structure generation means. 55.Computer software stored on a computer readable media, the computersoftware comprising program code for carrying out a method comprisingthe steps of: receiving source code that includes a higher ordercomputer language statement, said received source code having beencreated by a first computer program; generating machine code directlyinto random access memory (RAM) from the received source code; andproviding a function pointer to the generated machine code stored in theRAM so that a second computer program may access the generated machinecode.
 56. A computer-implemented apparatus for accessing machine code,comprising: a source code generation module to generate source code,said source code including a higher order computer language statement,said source code to be provided to a generator module so that thegenerator module may generate machine code directly into random accessmemory (RAM) from the source code; and a function location softwaremechanism to access the generated machine code stored in the RAM. 57.The apparatus of claim 56 wherein the function location softwaremechanism comprises an application programming interface (API) mechanismto access the generated machine code stored in the RAM through afunction pointer provided by the generator module.
 58. The apparatus ofclaim 56 further comprising: wherein the source code generation modulecomprises code generation means for generating the source code.
 59. Theapparatus of claim 58 wherein the code generation means comprisesstructure generation means.
 60. The apparatus of claim 58 wherein thecode generation means comprises exception handling code generationmeans.
 61. The apparatus of claim 60 wherein the exception handling codegeneration means generates higher order computer language statementsthat include an exception branching statement means and an exceptioncatching statement means.
 62. A computer-implemented method for handlingrun-time exceptions, comprising the steps of: receiving source code thatwas created by a computer program, wherein the received source codeincludes higher order computer language statements, wherein thestatements include an exception branching statement and an exceptioncatching statement; generating machine code directly into random accessmemory (RAM) from the received source code; and providing a functionpointer to the generated machine code stored in the RAM so that thecomputer program may access the generated machine code, wherein upon anexception occurring, execution of the generated machine code branches tothe exception catching statement in accordance with the exceptionbranching statement.
 63. The method of claim 62 wherein upon anexception happening, an exception signal handler allows execution toresume at recovery code associated with the exception catchingstatement.
 64. The method of claim 63 wherein the exception signalhandler allows execution to resume at the recovery code by placing thevalue stored from the exception branching statement into a PC (programcounter) slot of an exception context structure that was passed to theexception signal handler.
 65. The method of claim 64 wherein theexception branching statement includes ON_EXCEPTION_GOTO statementmeans.
 66. The method of claim 65 wherein the exception catchingstatement includes EXCEPTION_LABEL statement means.
 67. The method ofclaim 65 wherein the ON_EXCEPTION_GOTO( ) statement means recordslocation of the recovery code.
 68. The method of claim 62 wherein thecomputer program automatically generates the source code on-the-flyduring execution of the computer program.
 69. The method of claim 68wherein the computer program customizes the recovery code based uponcurrent context of the executing computer program.
 70. The method ofclaim 62 wherein the computer program customizes the recovery code basedupon current context of the executing computer program.
 71. The methodof claim 62 wherein the computer program comprises a data miningapplication.
 72. The method of claim 62 wherein the computer programcomprises a database application.
 73. The method of claim 62 wherein thecomputer program comprises a statistical application.
 74. The method ofclaim 62 wherein use of the exception branching statement reducescontinually saving the context of the executing generated machine codewhen trapping for exceptions.
 75. The method of claim 62 wherein use ofthe exception branching statement substantially eliminates continuallysaving the context of the executing generated machine code when trappingfor exceptions.
 76. The method of claim 62 wherein use of the exceptionbranching statement eliminates continually saving the context of theexecuting generated machine code when trapping for exceptions. 77.Computer software stored on a computer readable media, the computersoftware comprising program code for carrying out a method according toclaim
 62. 78. Computer software stored on a computer readable media, thecomputer software comprising program code for carrying out a methodcomprising the steps of: receiving source code that was created by acomputer program, wherein the received source code includes higher ordercomputer language statements, wherein the statements include anexception branching statement and an exception catching statement;generating machine code directly into random access memory (RAM) fromthe received source code; and providing a function pointer to thegenerated machine code stored in the RAM so that the computer programmay access the generated machine code, wherein upon an exceptionoccurring, execution of the generated machine code branches to theexception catching statement in accordance with the exception branchingstatement.
 79. A computer-implemented apparatus for handling run-timeexceptions, comprising: means for receiving source code that was createdby a computer program, wherein the received source code includes higherorder computer language statements means, wherein the statements meansinclude an exception branching statement means and an exception catchingstatement means; means for generating machine code directly into randomaccess memory (RAM) from the received source code; and means forproviding a function pointer to the generated machine code stored in theRAM so that the computer program may access the generated machine code,wherein upon an exception occurring, execution of the generated machinecode branches to the exception catching statement means in accordancewith the exception branching statement means.
 80. A computer-implementedapparatus for handling run-time exceptions, comprising: a generatormodule that generates machine code directly into random access memory(RAM) from source code, said source code including higher order computerlanguage statements, wherein the statements include an exceptionbranching statement and an exception catching statement, said sourcecode having been provided to the generator module by a computer program;a relocation handler that performs relocation operations duringgeneration of the machine code; said generator module providing afunction pointer to the generated machine code stored in the RAM so thatthe computer program may access the generated machine code, wherein uponan exception occurring, execution of the generated machine code branchesto the exception catching statement in accordance with the exceptionbranching statement, wherein use of the exception branching statementeliminates continually saving the context of the executing generatedmachine code when trapping for exceptions.